1. Technical Field of the Invention
The present invention relates to a call admission control (CAC) system and method for Internet Protocol (IP) Differentiated Services (DiffServ) network having at least one node for interpreting signaling messages and controlling traffic load in the network. In particular, and not by way of limitation, the present invention is directed to a system and method for interpreting signaling messages and controlling traffic load in IP network of Universal Mobile Telecommunication System Terrestrial Radio Access Networks (UTRAN) using only functionalities implemented in the IP network layer and the underlying layers.
2. Description of Related Art
IP networks were designed originally for best effort (BE) data services. Recently, there has been increasing demand to use IP networks for transmitting real-time traffic like voice, multimedia, or other delay-sensitive and jitter-sensitive traffic types. There are also plans to use IP in UTRAN as a transport protocol in mobile access networks, where, due to the mobility of the users, there are strict delay requirements and other Quality-of-Service (QoS) requirements for all traffic types. In IP UTRAN, real-time applications generate a large portion of the traffic. Thus, providing QoS guarantees (delay and loss) to real-time traffic is one of the most important requirements. As overload—either call level or packet level—in the system results in too large delay for most of the packets, it is essential to include functions that prevent overload situations. To protect against call level overload, therefore, the CAC algorithm is crucial.
DiffServ in IP-UTRAN
The current Third Generation Partnership Program (3GPP) agreements define the requirements against the IP UTRAN Transport Network Layer (TNL), but do not specify the way the TNL actually implements QoS. The QoS differentiation provided by the TNL can be based either on hop-by-hop or on end-to-end basis, and the TNL may support either flow-per-flow or aggregate classification. The necessary information for QoS differentiation among UTRAN flows is provided by the Radio Network Layer (RNL).
The transport network should be able to handle both UTRAN traffic and non-UTRAN traffic. Thus, existing QoS IP solutions should be used in the QoS architecture of the transport network. Due to scalability reasons, the DiffServ (DS) concept is preferred, nevertheless the IP UTRAN concept and the DiffServ concept differ in some important points.
The DiffServ architecture was originally designed for Internet backbones, which implies that several network providers own and operate it. The DS network, therefore, is divided into domains. At the boundaries of DS domains, traffic is regulated to allow e.g. charging and the operation of the internal of the domain. The parameters of services that a domain offers are described in the Service Level Specification (SLS), which includes a Traffic Conditioning Specification (TCS), which specifies how traffic conditioners should be configured.
The most frequently mentioned design goal of DiffServ is scalability. The large functional difference between (complex) boundary and (simple) interior nodes is due to this criterion. Traffic conditioning is one of the roles of boundary nodes, which is to measure the incoming flows and to ensure that they conform to the SLS/TCS. Boundary nodes are also responsible for marking/re-marking of incoming packets according to the Per Hop Behavior (PHB) that the flow requires inside the DiffServ domain. In contrast to this, interior nodes are typically not required to do traffic conditioning. Their task is to forward packets according to the required PHB signaled in the DS field of the IP header. Note that a PHB describes a special type of requirements demanded by flows, but it does not say anything about the exact mechanisms (such as scheduling method, buffer management, or policing method) that the router should include. It is up to the router designer how the router supports a specific PHB.
According to the DiffServ concept, neither boundary nodes nor interior nodes support CAC. If the traffic at a given ingress node i.e. the boundary node where the traffic enters the DiffServ domain exceeds the volume set in the SLS/TCS, then packets are dropped due to policing. However, policing is applied to the aggregate traffic, thus it degrades the performance of many real-time applications, as opposed to CAC, where the integrity of admitted connections is always preserved. Having recognized this fact, several solutions evolved proposing a session level control plane to the aggregate user plane of DiffServ and also proposing integration of Integrated Services (IntServ) and DiffServ networks.
RFC 2998 proposes a framework for supporting IntServ over DiffServ networks. According to the RFC, the IntServ capable part of the network includes RSVP-aware nodes, which inherently include per-session states in the forwarding and signaling planes. Edge nodes, which are at the edge of the IntServ capable part of the network, do call admission control on behalf of the DiffServ region, which does not maintain per-session states. Thus, DiffServ regions of the network are treated as virtual links connecting IntServ capable routers or hosts from the perspective of IntServ.
A next step in the evolution of DiffServ networks is when interior nodes also support a resource reservation signaling protocol, such as Resource Management in DiffServ (RMD). These solutions keep the user plane of DiffServ routers, which does not have per-flow separation, and add resource reservation to that.
Static Provisioning in DiffServ
In the current DiffServ architecture, no resource reservation signaling protocol is implemented within a DS domain. That is, interior nodes do not register ongoing connections and do not implement any admission control functionality. Furthermore, boundary nodes do not get any feedback about congestion in interior nodes.
To avoid overload, the bandwidth allocation inside the DS domain is static. Bandwidth allocation is typically implemented by two functions in DS routers, such as scheduling and policing. Scheduling, specifically weighted fair queuing (FQ), is a means for allocating a minimum guaranteed bandwidth for a given DS class. Policing, on the other hand, guarantees that the maximal bandwidth used by a given class is also limited.
Regarding dimensioning and admission control, a trunk reservation model can be used. A trunk is a virtual capacity allocated for flows with the same ingress (boundary node where traffic enters the DS domain) and egress (boundary node where traffic leaves the DS domain) nodes. Ingress nodes have to ensure—via admission control—that the aggregate (effective) bandwidth of flows in a trunk does not exceed the assigned trunk capacity. In other words, if the aggregate bandwidth of flows with the same ingress-egress boundary node—including the new request—would exceed the capacity of the corresponding trunk then the new request must be blocked. Once the ingress node admits a connection, other nodes in the domain cannot block it.
The following table summarizes the functions used in a statically provisioned network.
StaticFunctionprovisioningINTERIOR NODESBandwidth allocationStaticto DS classesConfiguration ofStatictraffic conditionersResource reservationNoprotocolAdmission controlNoBOUNDARY NODESAdmission controlYesResource reservationYesprotocolConfiguration ofStatictraffic conditioners
The trunk reservation idea can be extended to IP UTRAN systems where flows have strict delay requirements and there are multiple traffic classes. Two solutions can be applied in this context, which are as follows.
Multiple Single-Class Trunks
To construct a trunk reservation model in DiffServ, an apparent solution is to completely separate the handling of DiffServ classes in the admission control. That is, between an ingress-egress pair each QoS class has separated trunks. This solution is inline with the DiffServ concept, as it requires static bandwidth allocation for QoS classes in all nodes, including interior and boundary nodes (routers).
Single Multi-Class Trunk for Each Ingress-Egress Pair
The previous static provisioning method completely separates the resource reservation of flows having the same ingress-egress node but different DS class. By allowing statistical multiplexing between all flows within an ingress-egress pair, significant capacity gain can be achieved. This can be done by allocating a multi-class trunk between each ingress-egress pair of boundary nodes, as shows, instead of several single-class trunks as in the previous method.
Statistical QoS requirements of UTRAN traffic may be violated due to overload and due to short time-scale bursts in a normal (non-overloaded) situation. Classical CAC methods consider only overload caused by the on-off behavior of sources, but they do not protect against unacceptably long waiting times due to short time-scale bursts.
Resource allocation problem in UTRAN with ATM as transport network was investigated in Sz. Malomsoky, S. Rácz and Sz. Nádas, “Connection Admission Control in UMTS Radio Access Networks,” Computer Communications—Computer Communications 26 (2003) p. 2011-2023. This model was similar to the trunk model of IP UTRAN. However, they did not consider any QoS differentiation, that is, traffic was served in a common FIFO-queue. Based on analytic results, they presented a simple Call Admission Control method, which considers statistical delay requirements of UTRAN traffic.
This CAC method can be directly applied for IP UTRAN in case of single-class trunks, if large IP packets are segmented to sufficiently small segments. The main idea of this solution is to handle each DiffServ class separately. Separation means that the actual load of other QoS classes is not used in the call admission control. That is, regarding the load of other classes a worst case assumption has to be applied, i.e. they are assumed to be overloaded. When other classes are overloaded, the studied class can be handled as if it was a stand-alone FIFO system of which capacity is equal to the allocated bandwidth.
The waiting times in a DS queue in case of multi-class trunks are hard to determine analytically. However, a basic CAC approach can be presented that is based on the worst-case value of the service rate of each queue, which allows us to model each real-time queue as a separated FIFO-system in the network node. Under this assumption (referred as Separated FIFO model), CAC method for FIFO systems can be applied for multi-class trunks.
Thus, although the above-mentioned methods are suitable for reducing bandwidth capacity needs, each of them has disadvantages that limit their applicability. It would be desirable to have a method for IP networks that achieves a better utilization of the admissible region of the IP network in an efficient manner. Such a method would use only functionalities implemented in the IP network layer and the underlying layers, and would utilize an algorithm that is simple and fast. The method would not require high processing capacity, and it would be easy to implement. The present invention provides such a method.